To
put a few of the patterns in perspective, let's create a formal design
around a system that monitors application performance service-level
agreements (SLAs). In this design, a company already has a monitoring
product that can audit activity in existing SQL Server databases at
customer sites. Assume that the company that makes this monitoring
product wants to extend its services by offering a SQL Azure storage
mechanism so it can monitor customers' database SLAs centrally.
1. Pre-Azure Application Architecture
First, let's look
at the existing application-monitoring product. It contains a module
that monitors one or more SQL Servers in an enterprise and stores its
results in another database located on the customer's network.
In this example, Company A has
implemented the monitoring service against an existing ERP product to
monitor access security and overall SLA. The monitoring application
performs the auditing based on live activity on the internal SQL Server
storing the ERP data. When certain statements take too long to execute,
the monitoring service receives an alert and stores an audit record in
the local auditing database, as shown in Figure 1.
On a monthly basis,
managers run reports to review the SLAs of the ERP system and can
determine whether the ERP application is still performing according to
predefined thresholds as specified in the ERP vendor contract. So far,
the benefits of this implementation include the following:
However, the customer
needs to store the auditing data internally and manage an extra SQL
Server instance; this adds database management overhead, including
making sure all security patches (operating system and database) are up
to date. In addition, the local auditing database running on SQL Server
isn't readily accessible to the ERP vendor, so the ERP vendor can't
take proactive actions on any SLA issues and must wait to be informed
by the customer about serious performance issues. Finally, the customer
doesn't know how its internal SLA measures compare to other customers
running the same ERP product.
2. Azure Implementation
The monitoring provider
has created an enhanced version of its monitoring system and includes
an optional cloud storage option, in which the monitoring service can
forward performance events in a centrally located database in the
cloud. The monitoring provider has decided to implement an asynchronous
smart branching pattern so that events can be stored in a SQL Azure
database.
Figure 2
shows the implementation architecture that lets the monitoring service
store data in a cloud database. Each monitoring service can now store
SLA metrics in the cloud in addition to the local auditing database.
Finally, the local auditing database is an option that customers may
choose not to install. To support this feature, the monitoring provider
has decided to implement a queuing mechanism in case the link to SQL
Azure becomes unavailable.
The monitoring provider has
also built a portal on which customers can monitor their SLAs. Customer
B, for example, can now use the portal to monitor both its CRM and ERP
application database SLAs. The customer can prepare reports and make
them available to the ERP and CRM vendors for review online, with
complete drilldown access to the statements from the same portal.
In this implementation, additional benefits include the following:
Improved sharing.
Sharing information with vendors becomes much easier because drilldown
access to issues is provided through a cloud-enabled portal.
Local storage optional.
With the improved solution, customers may decide to implement the cloud
storage only if they're short staffed to handle the necessary internal
database-management activities.
External monitoring.
Customers A and B also have the ability to use the monitoring provider
to proactively monitor their ERP products remotely with specific
escalation procedures when the SLAs aren't met. The monitoring provider
can, for example, manage performance issues directly with the ERP
provider.